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1.  Scope. 

1.1.  Identification. 

This  document  defines  the  software  design  for  the  Vehicle  Integrated  Defense 
System  (VIDS)  simulation  and  its  inclusion  into  the  existing  Ml  Tank 
Simulator  software.  This  software  design  satisfies  requirements  contained 
within  the  VIDS  SRS. 

1.2.  System  overview. 

The  VIDS-equipped  Ml  Tank  Simulator  exists  to  support  a  series  of 
survivability  experiments.  The  nature  of  the  experiments  requires  that  the 
VIDS  simulation  be  parameter  driven.  The  VIDS  parameters  not  only  define 
available  sensors  and  countermeasures,  but  also  define  their  respective 
sensitivities  and  response  times.  For  the  present,  two  sensors  and 
countermeasures  are  simulated: 

Sensors 

a.  Laser  Warning  Receiver  (LWR). 

b.  Missile  Warning  System  (MWS). 

Countermeasures 

a.  Multi-Salvo  Smoke  Grenade  Launcher/Rapid 
Obscuration  System  (ROS). 

b.  Missile  Countermeasure  Device  (MCD). 

In  general,  the  VIDS  system  responds  to  perceived  threats  in  the  following 
ways: 

a.  by  displaying  visual  icons  on  the  Commander's  Controls  Display  Panel 
(CCDP). 

b.  by  generating  alert  tones  which  can  be  heard  on  the  tank  crew  intercom. 

c.  by  examining  user-selected  countermeasure  activation  modes. 

d.  by  seizing  control  of  the  turret. 

e.  by  activating  a  selected  countermeasure  for  each  perceived  threat. 

Because  VIDS  can  seize  control  of  the  turret,  automatic  turret  rotation  for 
counterfire  is  supported.  Furthermore,  VIDS  supports  automatic  turret 
slewing  for  visual  detection  of  threats. 

1.3.  Document  overview. 

This  document  identifies  and  describes  new  software  CSCs  and  CSUs,  as  well 
as  changes  to  and  reuse  of  existing  Ml  Simulator  CSCs  and  CSUs.  Diagrams 
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and  narratives  are  used  to  explain  how  the  new  VIDS  simulation  executes 
within  the  framework  of  the  existing  Ml  Simulator. 

2.  Referenced  documents. 

2.1.  Government  documents. 

SPECIFICATIONS: 

1.  PM-Survivability:  VIDS  Armored  Vehicle  Survivability 

Equipment  (AVSE)  BDS-D  Functional  Specifications,  29  May  1992. 

2.2.  Non-Government  documents. 

1.  Loral:  Software  Requirements  Specification  for  the  VIDS-Equipped 
Ml  Tank  Simulator  of  BDS-D,  Contract  No.  N61339-91-D0001, 
November  11,  1992 

2.  Loral:  Battlefield  Distributed  Simulation-Development  (BDS-D) 
Vehicle  Integrated  Defense  System  (VIDS)  Feasibility  Analysis 
Report,  14  October  1992. 

3.  BBN:  The  SIMNET  Network  and  Protocols,  Report  7627,  June  1991. 

3.  Preliminary  design. 

3.1.  CSCI  overview. 

The  VIDS-equipped  Ml  Tank  Simulator  (hereafter  referred  to  as  the  VIDS- 
equipped  simulator)  exists  as  one  of  many  entities  participating  within  a 
simulated  battle.  Each  entity  communicates  with  other  entities  by  sending 
and  receiving  Protocol  Data  Units  (PDUs).  The  external  interfaces  for  the 
VIDS-equipped  tank  are  illustrated  in  Figure  1. 


Incoming  PDUs  describe  the  activity  in  one  or  more  simulated  battlefields. 
Because  the  number  of  incoming  PDUs  can  be  quite  large,  a  series  of  high- 
level  filters  are  applied  to  retain  only  those  PDUs  which  are  applicable  to  a 
specific  entity.  Applicable  PDUs  are  then  filtered  based  upon  entity-specific 
parameters  such  as  distance  and  available  sensors.  Remaining  PDUs  are  then 
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classified  and  used  to  influence  either  the  entity  behavior  or  what  the  entity 
can  detect. 

Outgoing  PDUs  describe  the  visual  appearance  or  behavior  of  the  VIDS- 
equipped  simulator.  Typically,  these  define  the  current  tank  hull  position 
and  orientation,  the  turret  orientation,  the  presence  of  smoke  clouds  or  the 
existence  of  electro-optical  jamming  energy.  For  experimental  purposes,  a 
subset  of  the  outgoing  PDUs  contain  instrumentation  information  which  can 
be  used  by  analysts  to  better  understand  the  use  of  the  soldier-machine 
interface. 

3.1.1.  CSCI  architecture. 

The  VIDS  capability  is  partitioned  between  two  host  computers.  One  host  is 
the  current  Ml  tank  GT  hardware;  the  other  host  is  a  PC  with  an  Elographics 
touchscreen  mounted  in  front  of  a  13  inch  color  video  monitor.  The  software 
executing  on  the  PC  supports  the  Soldier  Machine  Interface  (SMI),  hereafter 
referred  to  the  as  the  CCDP.  This  includes  all  the  VIDS  buttons,  setup 
windows  and  the  display  windows.  The  software  executing  on  the  GT 
simulates  the  behavior  of  the  sensors,  countermeasures  and  threat  resolution 
module. 

The  VIDS-PC  and  VIDS-GT  communicate  with  one  another  just  like  other 
entities  participating  within  a  simulated  battle  exercise.  Because  there  may  be 
multiple  VIDS-equipped  simulators  within  the  same  exercise,  the  VIDS-PC 
and  VIDS-GT  are  paired  so  that  only  appropriate  network  messages  are 
recognized  and  processed.  In  other  words,  the  VIDS-PC  knows  the  unique 
identifier  (VehiclelD)  of  its  corresponding  VIDS-GT,  and  the  VIDS-GT  knows 
the  unique  VehiclelD  of  its  corresponding  VIDS-PC. 

3.1.2.  System  states  and  modes. 

The  VIDS-GT  as  a  functioning  CSCI  which  operates  in  one  of  six  predefined 
states.  These  states  are: 

a.  Startup. 

b.  Idle. 

c.  Initialize. 

d.  Simulate. 

e.  Stop. 

f.  Exit. 

Within  the  VIDS  context,  only  the  Startup,  Initialize  and  Simulate  states  are 
significant. 

During  the  Startup  State,  specific  hardware  devices  are  initialized  and 
parameter  files  are  read.  It  is  during  this  state  that  the  VIDS  parameter  file  is 
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read  to  establish  the  types  and  behaviors  of  available  sensors  and 
countermeasures.  This  file  also  defines  a  default  set  of  countermeasures  for 
each  type  of  threat.  After  having  read  all  the  parameter  files,  a 
communication  link  to  the  Simulation  Network  (SIMNET)  is  established. 
Having  successfully  completed  these  tasks,  a  transition  is  made  to  the  Idle 
State. 

During  the  Idle  State,  the  Ml  Tank  Simulator  waits  to  receive  an  activation 
request  from  SIMNET.  When  an  Activation  Request  PDU  is  received,  a 
transition  is  made  to  the  Initialize  State. 

During  the  Initialize  State,  more  extensive  hardware  and  internal  software 
initialization  is  performed.  For  VIDS,  internal  probability  tables  are  built;  and 
default  alert,  safety,  countermeasure  coverage  and  turret  scanning  sector 
settings  are  sent  to  the  VIDS-PC.  Having  successfully  completed  this 
initialization,  a  transition  is  made  to  the  Simulate  State. 

The  Simulate  State  represents  the  main  processing  loop  for  the  VIDS-GT. 
PDUs  sent  by  the  VIDS-PC  are  monitored  and  used  to  alter  the  behavior  of 
VIDS.  Electro-optical  PDUs  from  other  entities  are  read  and  used  to 
determine  if  a  threat  is  present.  When  a  threat  is  detected,  PDUs  are  sent  to 
the  VIDS-PC  to  provide  visual  and  audible  cues.  Furthermore,  detected 
threats  are  prioritized  and  countermeasures  are  activated.  The  Simulate  State 
continues  until: 

a.  An  impact  PDU  is  received  which  destroys  the  tank. 

b.  A  deactivation  PDU  is  received  which  forces  a  transition  to  the  Stop 
State. 

b.  A  reconstitute  PDU  is  received  which  forces  a  transition  to  the  Idle 
State. 

c.  An  exit  command  is  received  from  the  Ml  Console  keyboard  which 
forces  a  transition  to  the  Exit  State. 

During  the  Stop  State,  a  transition  is  made  to  the  Idle  State,  followed  by  a 
transition  to  the  Exit  State. 

For  the  VIDS-PC,  there  are  only  three  states:  Initialize,  Simulate  and 
Shutdown.  During  the  Initialize  State,  data  files  are  read  which  define  button 
positions,  content  and  behavior.  Furthermore,  the  VIDS-PC  waits  to  receive 
the  default  alert,  safety,  countermeasure  coverage  and  turret  scanning  sector 
settings  from  the  VIDS-GT.  Once  these  settings  have  been  received,  a 
transition  is  made  to  the  Simulate  State. 

As  with  the  VIDS-GT,  the  Simulate  State  represents  the  main  processing  loop 
for  the  user  interface.  The  touchscreen  is  continually  monitored  to 
determine  if  a  button  has  been  depressed  or  released.  Specific  button  actions 


-  4  - 


VIDS  SDD 


may  generate  brief  user  alert  messages  to  appear  on  the  display  panel. 

Changed  button  values  or  sector  widths  are  sent  back  to  the  VIDS-GT  to 
influence  the  behavior  of  the  sensors  and  countermeasures.  The  network 
buffer  is  continually  polled  to  determine  if  PDUs  sent  by  the  VIDS-GT  require 
updates  to  the  display  or  if  audible  alerts  must  be  activated  or  terminated. 

During  the  Shutdown  State,  dynamic  memory  is  released,  special  interrupt 
handling  is  suspended  and  control  is  released  to  the  normal  operating  system. 

3.1.3.  Memory  and  processing  time  allocation. 

At  the  present  time,  there  are  no  memory  budgets  more  restrictive  than  those 
imposed  by  the  respective  host  computers.  However,  the  VIDS-GT  functions 
which  execute  during  the  Simulate  State  must  execute  faster  than  1/15^  of  a 
second.  This  is  due  to  the  fundamental  execution  cycle  on  the  GT.  In  fact,  the 
VIDS  software  execution  speed  must  take  only  a  relatively  small  percentage 
(20%  or  less)  of  the  66.67  milliseconds  since  the  sum  total  of  all  simulated  Ml 
behavior  must  execute  within  this  time  frame. 

3.2.  CSCI  Design  Description. 

Because  the  simulated  VIDS  system  is  partitioned  between  two  host 
computers,  the  description  of  the  VIDS  CSC  is  divided  into  two  parts:  the 
VIDS-GT  CSC  and  the  VIDS-PC  CSC.  Note  that  the  VIDS-PC  CSC  is  also 
referred  to  as  the  Soldier  Machine  Interface  (SMI)  and  the  Commander's 
Controls  Display  Panel  (CCDP). 

3.2.1.  VIDS-GT  CSC 

The  VIDS-GT  CSC  handles  the  job  of  simulating  the  behaviors  of  available 
sensors  and  countermeasures.  Parameters  sent  by  the  VIDS-PC  CSC  are  used 
to  constrain  the  behavior  of  the  VIDS-GT  CSC.  Parameters  sent  by  the  VIDS- 
GT  CSC  to  the  VIDS-PC  CSC  are  used  to  inform  the  tank  commander  what  is 
known  about  any  hostile  threats.  Specific  design  features  include: 

a.  The  VIDS-GT  CSC  satisfies  all  requirements  presently  allocated  to  the 
GT.  Refer  to  the  table  in  Section  7  to  locate  which  specific 
requirements  are  satisfied. 

b.  TheVIDS-GT  CSC  is  subdivided  into  three  lower-level  CSCs: 
VIDS_File_Read,  VIDSJnit  and  VIDS_Simul. 

c.  Each  of  the  three  lower-level  CSCs  are  executed  in  sequential  order. 
VIDS_File_Read  and  VIDS_Init  are  executed  only  once; 
VIDS_Simul  is  executed  15  times  a  second  as  part  of  the  Ml  code 
which  executes  in  the  Simulate  State. 
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3.2.1.1.  VIDS_File_Read  CSC 

The  VIDS_File_Read  CSC  handles  the  job  of  reading  a  specific  text  file 
defining  the  available  sensors  and  countermeasures  and  the  corresponding 
behaviors.  Specific  design  features  include: 

a.  This  CSC  satisfies  the  requirements  for  a  parameter-driven  set  of 
sensor  and  countermeasure  behaviors.  Refer  to  the  table  in  Section  7 
to  locate  which  specific  requirements  are  satisfied. 

b.  This  CSC  sequentially  reads  a  specific  text  file.  Each  line  is  either  a 
comment  or  a  keyword-value(s).  Comment  lines  are  skipped. 
Keywords  are  used  to  discriminate  which  values  are  being  read,  what 
format  must  be  used,  and  where  they  must  be  stored. 

c.  The  text  file  containing  the  sensor  and  countermeasure  behaviors  is 
read  only  once. 

3.2.1.2.  VIDSJnit  CSC 

The  VIDS_Init  CSC  handles  the  job  of  preallocating  dynamic  memory, 
initializing  queues  and  sending  default  parameters  to  the  VIDS- PC.  Specific 
design  features  include: 

a.  This  CSC  does  not  satisfy  any  system-level  requirements. 

b.  This  CSC  handles  the  job  of  preallocating  and  initializating  the 
dynamic  memory  to  be  used  during  the  simulation  of  the  VIDS 
behavior.  Furthermore,  it  performs  a  critical  initialization  step  by 
sending  the  corresponding  VIDS-PC  a  set  of  default  alert,  safety, 
countermeasure  coverage  and  turret  scanning  sector  settings. 

c.  This  CSC  satisfies  the  design  requirements  for  preallocating  and 
initializing  dynamic  memory  and  providing  default  parameters  to 
the  VIDS-PC. 

3.2.1.3.  VIDS.Simul  CSC 

The  VIDS_Simul  CSC  handles  the  job  of  managing  the  majority  of  other 
lower-level  CSCs.  It  is  these  lower-level  CSCs  which  model  the  behavior  of 
the  available  sensors,  countermeasures  and  threat  resolution  module. 
Specific  design  features  include: 

a.  This  CSC  and  its  lower-level  CSCs  satisfy  a  majority  of  the  system- 
level  requirements  allocated  to  the  GT.  Refer  to  the  table  in  Section  7 
to  locate  which  specific  requirements  are  satisfied. 
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b.  This  CSC  handles  the  job  of  sequentially  executing  the  lower-level 
CSC s.  This  includes  getting  updates  from  the  VIDS-PC,  monitoring 
the  main  and  turret  power  states,  determining  if  there  are  new’ 
thread,  prioritizing  the  current  threats,  selecting  countermeasures, 
activating  countermeasures,  sending  updated  threat  status  to  the 
VIDS-PC  and  sending  countermeasure  activation  information  to 
other  entities  participating  within  the  same  simulated  battle  exercise. 

c.  This  CSC  satisfies  the  design  requirement  for  monitoring  the  main 
tank  and  turret  power  states. 

3.2.2.  PC-Resident  VIDS  CSC 

The  VIDS-PC  CSC  handles  the  job  of  simulating  the  CCDP.  This  includes  a 
set  of  multi-function  buttons  as  well  as  the  ability  to  activate  audible  alarms 
and  display  threat  information.  The  display  screen  is  used  to  portray  the  type 
and  position  of  threats  relative  to  the  tank.  Specific  design  features  include: 

a.  The  VIDS-PC  CSC  satisfies  all  requirements  presently  allocated  to  the 
SMI.  Refer  to  the  table  in  Section  7  to  locate  which  specific 
requirements  are  satisfied. 

b.  The  VIDS-PC  CSC  is  subdivided  into  3  lower-level  CSCs:  SMI_Init, 
SMI  Simul,  SMI_Shutdown. 

c.  Each  of  the  three  lower-level  CSCs  are  executed  in  sequential  order. 
SMI  Init  and  SMI  Shutdown  are  executed  only  once;  SMI_Smrul  [s 
executed  endlessly  until  a  keyboard  Control-C  or  right  mouse  button 
is  received. 
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4.  Detailed  Design. 

The  detailed  design  is  divided  into  two  parts.  The  first  part  describes  the 
VIDS-GT  CSC  and  the  second  part  describes  the  VIDS-PC  CSC. 

4.1  VIDS-GT  CSC  Detailed  Design 

4.1.1.  VIDS_File_Read  CSC 

VIDSJFile_Read  reads  a  text  file  of  parameters  for  available  sensors  and 
countermeasures.  This  CSC  is  executed  only  once  during  the  Startup  State  of 
the  existing  Ml  code.  The  text  file  contains  parameters  for  the  Laser  Warning 
Receiver,  Missile  Warning  System,  Missile  Countermeasure  Device  and  the 
Rapid  Obscuration  System.  Furthermore,  the  text  file  contains  automatic 
turret  rotation  rates  for  countermeasure  activation,  counterfire  and  turret 
scanning.  The  text  file  also  contains  the  unique  identification  (VehiclelD)  of 
the  PC  which  simulates  the  behavior  of  the  corresponding  CCDP. 

4.1.2.  VIDSJnitCSC 

VIDS_Init  preallocates  dynamic  memory  structures  which  are  used 
frequently  during  the  execution  of  the  VIDS_Simul  CSC.  Preallocation  is 
done  here  purely  for  efficiency  because  VIDS_Init  is  invoked  during  a  non- 
critical  processing  state. 

VIDS_Init  also  sends  default  settings  and  smoke  grenade  counts  to  the  CCDP. 
Alert,  satety,  countermeasure  coverage  and  turret  scanning  sector  settings  are 
graphically  portrayed  when  the  CCDP  is  powered  on. 

4.1.3.  VIDS.Simul  CSC 

VIDS_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  sensors, 
threat  resolution  module  and  countermeasures.  It  represents  the  root  of  a 
functional  hierarchy  which  is  executed  once  during  each  execution  cycle  of 
the  existing.  Ml  simulation  software.  During  a  single  execution  cycle,  the 
following  high-level  functions  are  executed: 

Get_CCDP_Updates(); 

React_to_Power_State_Changes(); 

Identify_Threats(); 

Manage_Countermeasures(); 

Send_Updates_to_CCDP(); 

Send_Updates_to_Network(); 
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Each  of  these  functions  represent  a  functional  sub-hierarchy  which  is 
described  in  the  following  sections. 

4.13.1.  Get_CCDP_Updates  CSU 

Get_CCDP_Updates  retrieves  the  current  CCDP  settings.  These  settings  are 
changed  by  user  interaction  with  the  touch  screen.  It  is  assumed  that  all  error 
checking  is  performed  by  the  VIDS-PC.  Consequently,  all  individual  values 
are  assumed  to  be  error-free  and  that  combinations  of  settings  are  legal.  For 
example,,  manual  activation  of  the  MCD  or  ROS  is  legal  when  Semi- 
Automatic  or  Automatic  CM  has  not  been  selected. 

4.1.3.2.  React_to_Power_State_Changes  CSU 

React_to_Power_State_Changes  determines  if  the  VIDS-GT  system  should 
continue  to  receive  sensor  input  and  activate  countermeasures.  This  is  done 
by  checking  that  both  the  tank  Master_Power  and  Turret_Power  are  on. 
Only  when  they  are  both  on  is  VIDS  on. 

When  VIDS  is  off,  internal  data  structures  used  to  maintain  knowledge  of 
threats  and  active  countermeasures  is  discarded.  Later  on  in 
SendJUpdates_to_CCDP,  the  VIDS_Power_State  is  sent  to  the  CCDP  so  that  a 
similar  cleanup  can  occur  on  the  VIDS-PC. 

4.1.3.3.  Identify _Threats  CSC 

Identify_Threats  serves  as  the  primary  entry  point  of  sensor  simulation.  A 
test  is  made  to  determine  if  there  are  any  new  threats  which  can  be  potentially 
detected  by  one  of  the  active  sensors.  If  one  or  more  new  threats  exist,  they 
are  placed  into  a  queue  for  later  processing.  Additional  processing  is 
performed  by  the  following  functions: 

Filter_Threats(); 

Manual_Threat_Update(); 

Sensor_Simul(); 

Each  of  these  functions  are  described  in  the  following  sections. 

4. 1.3. 3.1.  Filter_Threats  CSU 

Filter  Threats  examines  each  new  threat  and  determines  if  a  corresponding 
sensor  is  active.  Threats  which  do  not  have  a  corresponding  active  sensor  are 
discarded.  Note  that  an  active  sensor  is  defined  in  the  text  file  read  by 
VIDS_File_Read. 

4.1.3.3.2.  Manual_Threat_Update  CSU 
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Manual_Threat_Update  determines  if  an  existing  threat  has  been  manually 
deleted  by  the  VIDS-PC.  If  the  CCDP  settings  indicate  a  deletion,  the  supplied 
threat  identification  is  used  to  search  and  delete  its  record  from  the  prioritized 
threat  list. 

4.I.3.3.3.  Sensor_Simul  CSC 

Sensor_Simul  invokes  available  sensors.  This  is  done  by  looping  through  all 
possible  sensors  and  testing  if  they  were  activated  by  parameters  retrieved  by 
VIDS_FileJRead.  The  following  sensors  can  be  selected  and  simulated: 

LWR_Simul(); 

MWS_Simul(); 

Each  of  these  functions  are  described  in  the  following  sections. 

4.1.3.3.3.1.  LWR_Simul  CSC 

LWR_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  Laser 
Warning  Receiver  (LWR).  This  sensor  is  subdivided  into  two  functional 
parts:  one  which  simulates  reaction  delay  and  detection  probability,  and  one 
which  processes  new  threats  as  a  function  of  sensor-specific  coverage  limits. 
The  two  functional  parts  are 

Process_New_Laser_Threats(); 

Test_LWR_Coverage_Limits(); 

Each  of  these  functions  are  described  in  the  following  sections. 

4.1.3.3.3.1.1.  Process_New_Laser_Threats  CSU 

Each  new  threat  exists  in  a  waiting  queue.  Each  invocation  of 
Process_New_Laser_Threats  decrements  a  counter  associated  with  each 
threat.  The  prescribed  delay  time  for  laser  threats  was  retrieved  by 
VIDS_File_Read.  After  the  counter  for  a  specific  threat  reaches  zero,  a 
detection  probability  is  used  to  decide  when  a  threat  is  detected.  A  detected 
threat  is  moved  from  the  waiting  queue  to  the  new  threats  queue.  A 
nondetected  threat  is  deleted  from  the  wait  queue. 

4.1.3.3.3.1.2.  Test_LWR_Coverage_Limits  CSU 

Test_LWR_Coverage_Limits  performs  a  series  tests  to  determine  if  a  threat 
falls  within  the  currently  defined  alert  sector,  and  LWR  azimuth  and 
coverage  sectors.  The  alert  sector  is  one  of  the  current  CCDP  settings  and  can 
be  changed  at  any  time,  whereas  the  LWR  azimuth  and  coverage  sectors  were 
retrieved  by  VIDS_File_Read  and  remain  constant  during  the  simulation. 
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To  simplify  calculations,  the  threat  position  is  mathematically  transformed 
into  the  coordinate  system  of  the  tank  hull.  If  the  threat  falls  within  the  alert 
and  coverage  sectors,  it  is  added  to  the  wait  queue.  Otherwise,  the  threat  is 
discarded. 


4.I.3.3.3.2.  MWS.Simul  CSC 

MWS_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  Missile 
Warning  System  (MWS).  This  sensor  is  subdivided  into  two  functional  parts: 
one  which  simulates  reaction  delay  and  detection  probability,  and  one  which 
processes  new  threats  as  a  function  of  sensor-specific  coverage  limits.  The 
two  functional  parts  are 

Process_New_Missile_Threats(); 

Test_MWS_Coverage_Limits(); 

Each  of  these  functions  are  described  in  the  following  sections. 

4.1.3.3.3.2.1.  Process_New_Missile_Threats  CSU 

Each  new  threat  exists  in  a  waiting  queue.  Each  invocation  of 
Process_New_Missile_Threats  decrements  a  counter  associated  with  each 
threat.  The  prescribed  delay  time  for  missile  threats  was  retrieved  by 
VIDS_FiIe_Read.  After  the  counter  for  a  specific  threat  reaches  zero,  a 
detection  probability  is  used  to  decide  when  a  threat  is  detected.  A  detected 
threat  is  moved  from  the  wait  queue  to  the  new  threats  queue.  A 
nondetected  threat  is  deleted  from  the  wait  queue. 

4.1.3.3.3.2.2.  Test_MWS_Coverage_Limits  CSU 

Test_MWS_Coverage_Limits  performs  a  series  tests  to  determine  if  a  threat 
is  heading  towards  the  tank,  and  if  so,  checks  if  the  threat  falls  within  the 
currently  defined  alert  sector,  and  MWS  azimuth  and  coverage  sector  angles. 
The  alert  sector  is  one  of  the  current  CCDP  settings  and  can  be  changed  at  any 
time,  whereas  the  MWS  approach,  azimuth  and  coverage  sectors  were 
retrieved  by  VIDS_File_Read  and  remain  constant  during  the  simulation. 

To  simplify  calculations,  the  threat  position  is  mathematically  transformed 
into  the  coordinate  system  of  the  tank  hull.  If  the  threat  is  heading  towards 
the  tank  and  falls  within  the  alert  and  coverage  sectors,  it  is  added  to  the  wait 
queue.  Otherwise,  the  threat  is  discarded. 

4.I.3.4.  Manage_Countermeasures  CSC 

Mange_Countermeasures  serves  as  the  primary  entry  point  for 
countermeasure  simulation.  Countermeasure  simulation  satisfies  the 
requirement  to  prioritize  threats,  select  appropriate  countermeasures  and  to 


-  11  - 


VIDS  SDD 


activate  individual  countermeasures  for  each  threat.  These  activities  are 
accomplished  by  invoking  the  following  functions: 

Prioritize_Threats(); 

Select_Countermeasures(); 

Individual_CM_Simul(); 

Each  of  these  functions  are  described  in  the  following  sections.  Note  that 
Prioritize_Threats  and  Select_Countermeasures  are  invoked  only  when  the 
VIDS  power  is  on. 

4.1.3.4.1.  Prioritize_Threats  CSC 

Prioritize_Threats  establishes  which  threats  require  the  most  immediate 
activation  of  countermeasures.  Furthermore,  to  make  sure  that 
countermeasures  are  used  efficiently,  checks  are  made  to  determine  if  the 
available  sensors  are  providing  multiple  reports  for  the  same  threat.  If  this  is 
the  case,  only  one  countermeasure  is  activated.  Finally,  threats  are 
automatically  deleted  if  no  new  sensor  reports  are  received  within  a 
predefined  threat  lifetime.  These  activities  are  accomplished  by  invoking  the 
following  functions: 

Fuse_Correlate_Threats(); 

Sort_Prioritized_Threats(); 

Update_All_Prioritized_Threats(); 

Each  of  these  functions  are  described  in  the  following  sections.  Note  that 
Sort_Prioritized_Threats  is  invoked  only  when  the  queue  of  active  threats 
has  been  changed  through  an  addition,  update  or  deletion. 

4.1.3.4.1.1.  Fuse_Correlate_Threats  CSU 

Fuse_Correlate_Threats  attempts  to  find  a  threat  from  the  new  threats  queue 
in  the  prioritized  threat  queue.  Recall  that  an  new  threat  is  one  which  has 
been  recently  detected  by  a  sensor  and  may  not  yet  be  prioritized.  If  the  new 
threat  is  found  in  the  prioritized  threat  queue,  the  information  describing  the 
new  threat  is  used  to  update  the  prioritized  threat.  Otherwise,  the  new  threat 
is  moved  from  the  new  threats  queue  to  the  prioritized  threat  queue.  Note 
that  new  and  updated  threats  are  given  a  finite  lifetime.  The  threat  lifetime 
was  retrieved  by  VIDS_File_Read. 

4.1.3.4.1.2.  Sort_Prioritized_Threats  CSU 

SortJPrioritized_Threats  visits  each  threat  in  the  prioritized  threat  queue  to 
verify  each  threat  is  assigned  the  correct  priority.  Threats  which  have 
activated  a  countermeasure  are  lower  in  priority  than  threats  which  have 
not.  A  threat  which  is  inside  the  safety  sector  is  lower  in  priority  than  one 
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which  is  outside.  Laser  threats  are  higher  in  priority  than  missile  threats. 
When  two  threats  have  equal  priority,  the  one  which  is  closest  to  the  main 
gun  has  higher  priority.  When  two  threats  are  equal  in  angular  proximity 
from  the  main  gun,  the  one  which  will  be  reached  with  a  clockwise  turret 
rotation  has  higher  priority. 

4.I.3.4.I.3.  Update_All_Prioritized_Threats  CSU 

Update_All_Prioritized_Threats  visits  each  threat  in  the  prioritized  threat 
queue  to  decrement  its  lifetime.  When  the  lifetime  for  a  threat  reaches  zero, 
it  is  removed. 

4.1.3.4.2.  Select_Countermeasures  CSU 

Select_Countermeasures  assigns  countermeasures  to  new  threats  and 
reconfirms  that  the  current  countermeasure  for  an  existing  threat  is  correct. 
This  is  done  by  visiting  each  threat  in  the  prioritized  threat  list  and 
determining  if  it  has  been  assigned  a  countermeasure.  When  a 
countermeasure  has  not  been  assigned,  a  table  lookup  is  used  to  find  the  first 
available  countermeasure.  When  a  countermeasure  has  been  assigned,  a 
table  lookup  is  still  performed  to  confirm  that  the  countermeasure  is  still 
recommended.  This  is  done  because  the  type  of  threat  may  have  changed  due 
to  sensor  fusion  or  because  an  expendable  countermeasure  is  no  longer 
available. 

Once  each  threat  has  been  assigned  a  countermeasure,  a  check  is  made  to 
determine  if  there  has  been  a  manual  change  in  the  order  of  countermeasure 
activation.  If  the  CCDP  settings  indicate  a  change,  the  corresponding 
countermeasure  will  be  activated  first  in  Individual_CM_Simul. 

4.1.3.4.3.  Individual_CM_Simul  CSU 

Individual_CM_Simul  controls  the  activation  and  deactivation  of 
countermeasures.  In  general,  individual  countermeasures  are  sequentially 
activated  and  deactivated  until  all  threats  have  been  handled.  Only  in  special 
cases  are  concurrent  activations  supported.  Futhermore, 
Individual_CM_Simul  supports  automatic  modes  for  counterfire  rotation 
and  turret  slewing  if  countermeasures  cannot  be  activated. 

Countermeasure  activation,  counterfire  rotation  and  turret  slewing  can  all  be 
activated  automatically  or  semi-automatically.  (Semi-automatic  activation  is 
equivalent  to  automatic  activation  when  the  commanders  palm  switch  is 
engaged.)  Countermeasures  can  be  activated  manually  using  buttons  on  the 
CCDP,  but  manual  counterfire  rotation  and  turret  slewing  is  still  controlled  by 
either  the  tank  commander  or  gunner  controls.  Note,  however,  that  all 
countermeasure  activations  require  arming.  A  button  on  the  CCDP  arms 
countermeasure  activations. 
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Manual  countermeasure  activation  occurs  when  countermeasures  are  armed 
and  the  Jam  or  Salvo  switch  is  depressed  (backlighted)  on  the  CCDP. 

Jamming  continues  endlessly  until  either  the  Jam  switch  is  released  or 
countermeasures  are  made  safe  (disarmed).  The  Salvo  switch  initiates  a  brief, 
timed-delay  which  results  in  smoke  appearing  in  out-the-window  displays 
and  switch  release  (the  CCDP  SALVO  button  backlighting  is  extinguished). 
Furthermore,  manual  jamming  or  a  salvo  of  smoke  grenades  can  occur 
concurrently  with  any  mode  of  turret  slewing. 

Automatic  countermeasure  activation  occurs  when  all  of  the  following 
conditions  exist: 

a.  the  recommended  countermeasure  for  a  threat  is  available. 

b.  countermeasures  are  armed. 

c.  the  commanders  palm  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

Furthermore,  automatic  modes  for  both  counterfire  rotation  or  turret  slewing 
are  ignored. 

Automatic  rotation  for  counterfire  will  occur  if  the  following  conditions  exist: 

a.  the  conditions  for  automatic  countermeasure  activation  do  not  exist. 

b.  counterfire  is  in  either  the  automatic  or  semi-automatic  mode. 

c.  the  commanders  palm  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

Furthermore,  automatic  modes  for  turret  slewing  are  ignored. 

Automatic  turret  slewing  will  occur  if  the  following  conditions  exist: 

a.  the  conditions  for  automatic  countermeasure  activation  do  not  exist. 

b.  counterfire  is  in  the  manual  mode. 

c.  the  commanders  palm  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

The  following  countermeasures  can  be  selected  and  simulated: 

ROS_Simul(); 

MCD_Simul(); 

Each  of  these  functions  are  described  in  the  following  sections. 

4.I.3.4.3.I.  ROS_Simul  CSU 

ROS_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  Rapid 
Obscuration  System  (ROS).  This  system  launches  smoke  grenades  to 
temporarily  hide  the  tank  position  from  electro-optically  guided  or  terminal 
homing  missile  threats. 
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For  simulation,  the  turret  is  conceptually  divided  into  24  equal  sectors  each 
with  15  degrees  of  coverage.  Each  sector  may  contain  zero  or  more  grenades; 
and  there  may  be  more  than  one  smoke  grenade  type. 

For  manual  activation,  the  number  and  sectors  are  specified  by  the  CCDP 
coverage  sector.  After  a  brief  time  delay,  smoke  grenades  are  launched  a  short 
distance  from  the  tank  hull.  The  delay  time  and  launch  distance  were 
retrieved  by  VIDS_File_Read. 

For  automatic  activation,  launch  sectors  are  selected  dynamically.  Launch 
sectors  are  selected  which  require  the  minimum  turret  rotations  to  get  the 
recommended  smoke  grenades  between  the  threat  and  the  tank  hull.  After 
the  predefined  time  delay  and  the  turret  has  rotated  a  launch  sector  into 
position,  one  or  more  grenades  are  launched  from  adjacent  sector  positions. 
Note  that  if  turret  rotation  is  required,  gunner  and  commander  turret 
controls  are  disabled. 

As  grenades  are  launched,  the  inventory  of  available  smoke  grenades  is 
decremented.  Once  all  the  recommended  grenades  have  been  launched,  the 
prioritized  threat  record  is  updated  so  that  additional  smoke  grenades  will  not 
be  launched  towards  the  same  threat;  gunner  and  commander  turret  controls 
are  enabled. 

4.I.3.4.3.2.  MCD_Simul  CSU 

MCD_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  Missile 
Countermeasure  Device  (MCD).  This  system  directs  infrared  jamming  energy 
towards  a  missile  threat  platform  to  disrupt  the  missile  tracking  system. 

For  simulation,  the  center  of  the  jamming  energy  is  coincident  with  the 
direction  of  the  main  gun.  The  azimuth  and  elevation  coverage  sectors  were 
retrieved  by  VIDS_File_Read. 

For  manual  activation,  the  jamming  energy  continues  until  it  is  manually 
deactivated.  For  automatic  activation,  the  jamming  begins  when  the  turret  is 
positioned  towards  the  threat  platform.  Note  that  if  turret  rotation  is 
required,  gunner  and  commander  turret  controls  are  disabled.  Jamming  is 
activated  for  a  brief  time.  The  automatic  activation  time  was  retrieved  by 
VIDS_File_Read.  Once  the  jamming  is  deactivated,  the  prioritized  threat 
record  is  updated  so  that  that  infrared  jamming  energy  will  not  be  directed 
against  the  same  threat;  gunner  and  commander  turret  controls  are  enabled. 

4.I.3.5.  Send  _Updates_to_CCDP  CSC 


-15- 


VIDS  SDD 


Send_Updates_to_CCDP  serves  as  the  primary  communication  channel  for 
sending  information  updates  from  the  VIDS-GT  to  the  VIDS-PC.  The 
following  types  of  information  are  sent: 

a.  Changes  to  the  top  six  threats. 

b.  Changes  to  hull  or  turret  orientations. 

c.  Changes  to  master  or  turret  power  states. 

d.  Audible  alerts  for  new  or  changed  threats. 

e.  Changes  in  smoke  grenade  grenade  inventory. 

Services  provided  by  existing  code  are  used  to  package  and  transmit  the 
information  to  the  corresponding  VIDS-PC. 

4.I.3.6.  Send_Updates_to_Network  CSC 

Send_Updates_to_Network  serves  as  the  primary  communication  channel 
for  sending  the  state  of  the  VIDS-equipped  tank  to  other  entities  participating 
within  the  same  simulated  battle  exercise.  The  following  types  of 
information  are  sent: 

a.  The  presence  of  smoke. 

b.  The  activation /deactivation  of  infrared  jamming. 

c.  Instrumentation  (used  only  for  data  collection  and  analysis). 

Services  provided  by  existing  code  are  used  to  package  and  transmit  the 
information  to  other  entities. 

4.1.4.  XField  CSC 

XField  handles  the  low-level  simulation  of  electo-optical  energy.  XField 
PDUs  retrieved  from  the  network  are  examined  to  determine  the  kind  and 
spatial  extent  of  electro-optical  energy.  If  the  VIDS-equipped  tank  falls  within 
the  energy  field,  the  information  describing  the  field  is  added  to  an  internal 
list  of  other  fields.  Additionally,  the  presence  of  clouds  (smoke)  is  used  to 
determine  if  the  field  energy  is  absorbed.  If  a  field  absorbed,  the  field  is  not 
made  available  to  the  higher-level  Identify_Threats  CSC. 

Fields  are  removed  from  the  list  when  either  an  explicit  XField  PDU  defines 
that  the  field  no  longer  exists  or  the  specified  field  lifetime  expires. 

An  Xfield  PDU  sent  by  the  VIDS-equipped  tank  (refer  to  the  MCD_Simul 
CSU)  is  tagged  appropriately  to  distinguish  it  from  fields  sent  by  other 
vehicles.  Furthermore  this  type  of  field  is  periodically  retransmitted  to  the 
network  as  long  as  the  field  is  present. 

4.1.5.  Cloud  CSC 
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Cloud  handles  the  low-level  simulation  of  smoke  clouds.  Smoke  Cloud 
PDUs  are  initially  transmitted  to  the  network  by  the  VIDS-equipped  tank 
(refer  to  the  ROS_Simul  CSU)  to  inform  other  vehicles  that  new  smoke 
clouds  exist. 

Each  smoke  grenade  is  simulated  as  a  single  cloud.  Parameters  are  supplied 
which  define  the  smoke  type  and  corresponding  spatial  dynamics.  This 
allows  other  vehicles  to  model  the  smoke  growth,  dissapation  and 
interference  with  electro-optical  energy. 

Like  XFields  PDUs,  Cloud  PDUs  are  periodically  retransmitted  to  the  network 
as  long  as  the  smoke  is  potentially  effective  as  an  obscurant.  When  the 
smoke  from  a  grenade  is  no  longer  effective,  a  Cloud  PDU  is  transmitted  to 
the  network  so  that  other  vehicles  can  drop  it  from  their  internal  lists. 

4.1.6.  Modifications  to  Existing  Code 

Modifications  to  existing  code  were  made  to  support  the  VIDS-GT  capability. 
The  files  and  changes  follow: 

a.  ml_main.c 

Added  invocation  of  VIDS_Init  in  veh_spec_init  function. 

Added  invocation  of  VIDS__File_Read  in  veh_spec_startup. 

Added  invocation  of  VIDS_Simul  in  veh_spec_simulate. 

b.  ml_turret.c 

Added  the  set_vids_az  function  to  support  automatic  turret  rotations 
to  specific  azimuth  angles. 

Added  the  set_vids_relative  function  to  support  final  turret  angles 
relative  to  the  tank  hull. 

Added  the  set_vids_north  function  to  support  final  turret  angles 
relative  to  true  north. 

Added  the  set_vids_auto_on  function  to  disable  the  gunner  and 
commander  turret  rotation  controls. 

Added  the  set_vids_auto_off  function  to  enable  the  gunner  and 
commander  turret  rotation  controls. 

Added  the  set_vids_slew_rate  function  to  support  the  specification  of 
a  rotation  rate. 

Added  the  get_vids_rate  function  to  retrieve  the  current,  VIDS-specific 
turret  rotation  parameters. 

c.  proc_a_pkt.c 

Added  code  to  recognize  ROS  resupply  so  that  the  initial  supply  and 
placement  of  smoke  grenades  could  be  instantly  restored. 

4.2.  VIDS-PC  Detailed  Design 
4.2.1.  SMIJnitCSC 
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SMI_Init  preallocates  dynamic  memory  structures  associated  with  drawing 
menus  and  displays  which  will  be  seen  during  the  execution  of  the 
SMI_Simul  CSC.  Data  files  are  read  which  define  the  placement  and 
appearance  of  buttons  and  icons  as  well  as  the  unique  identifier  (VehiclelD)  of 
its  corresponding  GT.  Parameters  are  read  which  define  active  buttons  and 
how  long  they  must  be  pressed  for  a  corresponding  action  to  be  activated. 
Finally,  links  are  established  between  buttons  and  function  invocations. 

4.2.2.  SMI_Simul  CSC 

SMI_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  real 
CCDP.  It  represents  the  root  of  a  functional  hierarchy  which  is  executed 
endlessly  until  a  keyboard  Control-C  or  right  mouse  button  event  is  received. 
During  a  single  execution  cycle,  the  following  high-level  functions  are 
executed: 

Get_Button(); 

Check_Alarms(); 

Process_Rcv_PDU(); 

Each  of  these  functions  represent  a  functional  sub-hierarchy  which  is 
described  in  the  following  sections. 

4.2.2.1.  Get_Button  CSU 

Get_Button  serves  the  need  to  monitor  button,  mouse,  and  keyboard  activity. 
A  right  mouse  button  or  keyboard  Control-C  signals  a  request  to  terminate 
the  SMI_Sinmd  CSC  by  transitioning  to  SMI_Shutdown.  Otherwise,  a  test  is 
made  to  determine  if  a  displayed  button  has  been  held  down.  If  a  button  has 
been  held  down  long  enough  and  it  corresponds  to  a  predefined  action,  the 
action  is  initiated  through  a  corresponding  function  call.  The  corresponding 
function  may  change  the  current  menu,  the  content  of  the  display,  the 
operating  state  or  a  combination  of  these  changes.  When  a  button  changes 
one  of  the  VIDS  operating  states,  a  network  message  is  sent  to  the  VIDS-GT  to 
update  its  corresponding  CCDP  settings  Additionally,  when  any  button  state 
is  changed  or  when  a  user  alert  message  is  displayed,  a  network  message  is 
sent  for  data  collection  and  analysis. 

4.2.2.2.  Check_Alarms  CSU 

Check_Alarms  manages  the  VIDS  alarm  tones  heard  on  the  tank  intercom. 
The  status  of  each  alarm  type  is  checked  to  determine  if  it  should  be  activated 
or  terminated.  When  an  alarm  is  activated,  the  alarm  is  heard  for  a 
predefined  duration.  An  alarm  is  terminated  when  the  duration  has  expired, 
a  termination  message  was  received  from  the  GT  or  VIDS  is  powered  off. 

4.2.2.3.  Process_Rcv_PDU  CSC 
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Process_Rcv_PDU  manages  received  network  messages.  Only  messages  sent 
by  the  corresponding  VIDS-GT  are  processed.  All  other  messages  are 
discarded. 

Depending  upon  the  type  of  message,  the  display  or  alarm  tones  are  changed. 
The  message  types  which  change  the  display  include  the  following: 

a.  Tank  Power  State  updates. 

b.  Tank  Orientation  updates. 

c.  Prioritized  Threat  updates. 

d.  Automatic  CM  Activation/Deactivation  updates. 

e.  Default  Setups. 

Only  the  Alarm  Control  message  type  affects  what  is  heard  on  the  tank 
intercom.  Refer  to  the  IDD  in  section  5  for  the  exact  content  of  each  message 
type. 

4.2.3.  SMI_Shutdown  CSU 

SMI_Shutdown  releases  memory  allocated  during  SMI_Init  and  restores  the 
mouse  and  display  behaviors  before  terminating. 
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5.  CSCI  data. 

Within  the  VIDS-GT  CSC,  there  is  only  one  global  data  element:  vids_debug. 
It  it  a  boolean  object  which  is  toggled  between  two  states  to  either  activate  or 
deactivate  diagnostic  messages.  Under  normal  conditions,  vids_debug  is 
false. 

Within  the  VIDS-PC  CSC,  the  following  arrays  represent  global  elements: 

a.  Icon. 

b.  Threat. 

c.  Frame. 

d.  Display. 

e.  Vary. 

f.  Buttons. 

g.  fcnptrs. 

These  arrays  used  to  support  low-level  drawing  operations.  Refer  to  the 
following  header  files  for  more  details: 

global.h 
alarm. h 
buttons. h 

The  following  table  lists  the  type  and  content  of  the  messages  exchanged 
between  the  PC,  GT  and  SAF. 
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Delta  0  to  360  degrees.  Defines  the  angular  offset  from  the  start  angle.  The 

sector  defined  by  the  delta  from  the  start  angle  is  evenly 
divisible  by  15  degrees. 
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countermeasure  may  be  activated  manually  or 
automatically.  Manually  deactivating  the  MCD 
countermeasure  immediately  terminates  either  type  ot 
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activation.  Manual  activation  always  requires  manual 
deactivation;  automatic  deactivation  follows  automatic 
activation  after  a  predefined  delay. 
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6.  CSCI  data  files. 

Files  are  not  shared  between  VIDS  CSCs  or  CSUs. 

7.  Requirements  traceability. 

The  following  table  depicts  the  requirements  traceability. 
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activity  to  all  participants  in  the  exercise. 
Have  weapons  systems  using  RF  uplink, 
or  other  RF  uses  communicate  the  prese 
characteristics  of  this  activity  to  all  partici 
deleted. 
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8.  Notes. 
Acronyms 

CCDP 

GT 

LWR 

MCD 

MWS 

PC 

ROS 

SAF 

SIMNET 

SMI 

VehiclelD 


VIDS 


Definitions 

Commander’s  Controls  Display  Panel 
Graphics  Technologies 
Laser  Warning  Receiver 
Missile  Countermeasure  Device 
Missile  Warning  System 
Personal  Computer 
Rapid  Obscuration  System 
Semi-Automated  Forces 
Simulation  Network 
Soldier  Machine  Interface 
An  integer  triplet  consisting  of  site,  host  and 
vehicle  numbers.  Used  to  uniquely  identify 
an  entity  within  a  battle  exercise. 

Vehicle  Integrated  Defense  System 
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